The 

FileMaker 


A Journal For FileMaker^'^ Users 



Stupid FileMaker Mistakes or Don’t Do That!’*' 


By Mike Harris and Joe Kroeger 

Rats! I DID IT again!” When you hear a File¬ 
Maker user say this out loud - or when you hear 
it echoing around inside your head - you may 
have run across yet another SFM: the dreaded 
Stupid FileMaker Mistake. Whether you are a 
beginner or, like the contributors to this article, 
have used FileMaker every day for years, there 
seems to be a set of stupid mistakes that keep 
recurring - errors and misdirections so easy to 
make that we “never seem to learn”. 

It might be argued that these common ‘oops’ 
actions represent evidence of bad interface design. 
Theoretically, in good Macintosh programs it 


A patient complained to the doctor while raising 
his arm over his head “Hey doc, it hurts when I do 
this.” The doctor replied “Don’t Do That!” Clearly 
a worthy prescription for FileMaker users too. 


should be easier to do the right thing than the 
wrong. Still, programmers of complex applica¬ 
tions often get into ‘see-saw’ design quandaries: 
make one thing easier and another is made more 
difficult. Further, a nice and simple action in one 
context may be a terrible choice in another. This 
makes some SFMs operator-dependent. What 
may be right or wrong in a given instance will not 
therefore be known to the program. 

In any reasonably sophisticated application 
there will probably be an irreducible number of 
unpreventable stupid mistakes available for users 
to find and enjoy. FileMaker is considered by 
some casual users and many non-users to be a 
simple, unsophisticated, database that has ‘only’ a 
flat-file structure. Ha. Truth to tell, FileMaker is a 
combination of significant database power and 
flexibility that is also easily accessible to end-us¬ 
ers. Some SFMs seem to flow naturally from such 
characteristics, although FileMaker's good inter¬ 
face certainly minimizes them. 
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A practical strategy is needed for avoiding 
awful SFMs and for dealing with them when they 
do arise. We have collected here some great SFMs 
from a few experienced users and hope that aware¬ 
ness of these pitfalls will help the reader develop 
the sixth sense required to avoid the time we’ve 
lost making these same mistakes too often’*^. Be 
aware, however, that, by definition, an SFM is 
easy to make and hard to avoid. You tend to re¬ 
member the SFM only after you’ve stepped in it; 
the secret is to see it coming! 

An SFM may be defined as: 

• a mistake that is not hard to understand and 
does not require delicate judgments about trade¬ 
offs, it is just 

• easy to make before you see it coming, and so 

• it tends to get repeated over and over again, and 

• wastes a lot of time, and 

• FileMaker work would be a lot more fiin if it 
could be avoided. 

Think of this article as basic training for SFM 
avoidance. 

^ Most of all, don't get in deeper. 

The very first rule when you find yourself in a 
deep hole is to put down the shovel! If you don't 
manage to see the mistake before it overtakes you, 
avoid the deadly reflex to try to “catch” the prob¬ 
lem with a quick lunge at the keyboard. Com¬ 
mand-period will hardly ever save you. If you can 
manage to avoid any further action after first 
making a mistake, you might be able to Undo it. 

If you have an SFM example of your own, share it 
(and perhaps your embarrassment) with other sub¬ 
scribers. Not only will we pay you our usual 15<tper 
word for your published material, well also add a 
free issue to your subscription. And just think how 
much fun it will be to expose your mistakes in print 
to the FileMaker community. 


Try to develop a substitute reflex of moving your 
hands immediately off the keyboard and mouse, 
providing time to carefully plot your next move. 
You might try grabbing your face a la Macaulay 
Culkin if that’s what it takes. You may look silly 
in the office but you also might buy yourself the 
ability to recover that will otherwise be destroyed 
by that one extra thoughtless move. Ultimately, if 
you can develop this defensive reflex before mak¬ 
ing an SFM, you will have, unlike us, beaten the 
SFMs altogether. 

Don't Change File Names. 

FileMaker files are frequently used as lookups 
- even single-file databases often use self-lookups. 
Any lookup is defined using the current name of 
the lookup file and if you change that file name 
FileMaker gets confused when the lookup is at¬ 
tempted. Although you get an opportunity to 
point to the proper lookup file when FileMaker 
can’t find the original name, this has to be done 
for every lookup field in the database every time 
the database is opened. The practical result is that 
you have to go back and redefine all the lookups 
to recognize the new file name(s). 

This can all be avoided by deciding on perma¬ 
nent file names at the very beginning of database 
development and sticking to these names. File 
names are worth extra consideration in any event: 
good names help make the database easier to use, 
bad names seem always to get in the way. The 
guidelines for good file names are similar to some 
of the rules for good writing: 

• the name should say as much as possible about 
what the file does; 

• use a single word name if it does not conflict 
with the point above; 

• use shorter rather than longer words; 

• use concrete rather than vague words; 

• avoid jargon; 

Examples of file names (left column) and pos¬ 
sible alternatives (right column): 
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SOE Data Entry 
Sales Orders 
GRLU 
Names 

Correspondence 
Zip\City\State Table 


Sales Orders 

Orders 

Rooms 

Customers 

Letters 

Zip LU 


To help identify file functions, especially for 
lookups, it can be helpful to standardize your 
own naming conventions such as adding “LU” or 
“Lkup” to the names of lookup files. Names like 
ClientAddrLU aid clarity. 

It is tempting to alter file names when moving 
from one year to another. You might think it nice 
to rename last year’s Orders file as Ordersl992. 
Usually, however, you want to avoid this by plac¬ 
ing the older files in a folder with a dated name but 
leaving the original file names intact. (One time a 
file name change is helpful is if you want lookups 
defeated. You might do so for an archived file 
which you never want changed or to be sure an 
older file is never mistakenly used for a lookup by 
current files.) 

Self-lookup files require particular attention. 

In this case, note that if you change the name of 
the destination file you are, necessarily, changing 
the name of the lookup file as well. The lookups 
that refer to an external file will not be disturbed, 
but the self-lookups must be redefined. Example: 
you've made a great address file that has several 
self-referent lookups, but it is accumulating more 
and more records. You decide to split your data¬ 
base into multiple files based on geographic loca¬ 
tion. When you clone the original and name it, 
you'll need to redo the self-lookups. 

After making a clone or copy of a file, whether 
in FileMaker or at the desktop, be very careful 
when renaming the new file, especially if it is a 
lookup. Nearly invisible spaces either before or 
after the name will cause FileMaker to say it can’t 
find the file if it is being used in a lookup. Which 
leads to the follovung SFM. 


Don't be careless with extra spaces. 

Extra spaces before and after words may be 
effectively invisible to you as data is entered or 
files are named, but those spaces make a huge 
difference to FileMaker. If you are a touch-typist 
or just rather hyper, you may be moving so fast 
that you inadvertently enter extra spaces in file 
and field names and during data entry. These 
extra spaces can make your life miserable. Maybe 
you should slow down a bit - in the long run your 
productivity might be better at a slower typing 
speed. Learn to be on the lookout for a cursor 
floating too far to the left or right of a word - a 
sure sign of an extra space. If this category of SFM 
arises often for you, consider using the Trim 
function when writing calculations: Trim will 
remove extra leading and trailing spaces on words 
or text strings that are subsequently used in calcu¬ 
lations. For instance, a formula for a lookup 
match code in an address file might be: 

Match = {text result} 

FirstName & LastName & ZIP 

With Trim included it could look like: 

Match = (text result} 

Trim (FirstName) & Trim (LastName) & ZIP 

If you double-click field names from the field 
list when working in the calculation definition 
dialog, you won’t have any trouble with spaces - 
FileMaker puts the right name in your equation. 

It always helps the extra space-problem to add 
text with mouse clicks rather than by typing. For 
data entry, use pop-up lists and menus and look¬ 
ups where you can. 

Exit the Define Equation dialog using 
"Cancel" if you have not made a change. 

Before FileMaker accepts a new equation, it is 
examined for internal consistency and for proper 
references to other fields and formulas. In large 
and complex files this examination can take time 
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- wasted time if you haven’t made any changes. 
When exiting the formula box after simply look¬ 
ing at the formula or copying a phrase for use 
elsewhere, always use the Cancel button, which 
does not trigger any examination of the formula. 

^ Don't experiment with changes to 
calculation definitions on a large file. 

This is a biggie. It is very tempting to make 
“just a little” change to a calculation without tak¬ 
ing the trouble to create a clone and import a few 
records for use as a working file for trying equa¬ 
tion changes. This is a big mistake. When you 
make any changes to a formula, FileMaker, quite 
rightly, recalculates the new values for all the 
records in the file. This can take a remarkably 
long time, particularly since it is so easy to make 
small errors in a formula which then necessitate 
another recalculation (and perhaps another, and 
another...). 

The really wonderful disasters result when you 
make a change to a formula which is itself used in 
Other calculations. One of us did this once on a 
file with about 2500 records and triggered 40 re¬ 
calculations. The file took fully two hours to once 
again become available for work! 

If the file contains only a few records, no prob¬ 
lem. But for debugging a calculation or set of cal¬ 
culations for a large file, make a working clone. 
When you are satisfied that all is well you can 
either replicate the calculations in the main file, 
or import into the clone the original data records. 

Don't move a lookup file into another 
folder (unless you put an alias in its place). 

We told you these were stupid mistakes. It is 
easy to forget that FileMaker needs to know 
where to find lookup files. Don’t move a lookup 
file out of the folder where FileMaker expects to 
find it or move a main file out of a folder and 
neglect to take associated lookup file(s) with it. A 
related mistake is copying files onto a floppy for a 


demonstration on another machine and forget¬ 
ting to bring aU the required lookups along. 

Ouch. If you keep related FileMaker files in a sin¬ 
gle functional folder and move them as a unit, it 
can make life much easier. 

Remember that Slide doesn't show on the 
screen in Browse mode. 

This seems fairly obvious but it is easy to for¬ 
get that you can’t count on the Slide feature when 
designing layouts for use in Browse mode. Slide 
is designed for printing, not for browsing - one 
reason that Preview exists. If it is important that 
the Browse display and the printed output be the 
same, you can often create calculations that com¬ 
bine the sliding fields just for display purposes. 

Never let layout objects touch Part 
boundaries unless you want a special effect. 

FileMaker gets very confused when layout 
objects (fields, labels, graphics, whatever) touch 
or overlap Part lines. In tight layouts it is often not 
obvious that objects in fact are touching Parts but 
it can mangle the whole layout. The magnifica¬ 
tion option in FileMaker is quite handy in Layout 
to detect such overlap. The nudging with the ar¬ 
row keys can help move an object just a little bit. 

On the other hand, it is OK to experiment 
with touching or crossing Part lines when you are 
trying to achieve special effects. Just remain aware 
of the exact position of objects on layouts. Re¬ 
member: you have to be accurate to the nearest 
single pixel to be sure. 

Start all files with Record Number, Creation 
Date, and Modification Date fields. 

The Record Number field is essential for sev¬ 
eral useful tricks involving self-lookups. Creation 
Date and Modification Date are invaluable for 
finding and correcting bad records. Trust us on 
this one. No matter what you think you are going 
to do with a file, no matter how small or appar- 
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endy trivial the file is, always include these fields. 
In fact, many of us have a template with these 
three fields already in it (plus other standard ele¬ 
ments which should be in every FileMaker file - 
such as perhaps a layout named “Data Entry”) 
and use a copy of the template as the starting point 
of every file we create. 

(If, after a newly-designed file is complete, 
debugged, and in service, you find that one of 
these base fields is not needed, you could delete it 
in the interest of saving space. Some stable lookup 
files don’t always need a Record Number field, 
for instance.) 

^ Beware of trying to enter a new record 
while in Find mode (rather than Browse). 

This is a classic SFM. Some of us are consult¬ 
ants with clients who regularly say “I’m positive I 
entered that record and it just disappeared!” This 
is virtually always a case of entering a record while 
in Find mode. 

Some users who have worked with FileMaker 
since 1985 still do it. (You know who you are!) It 
is especially easy to be tripped-up when you have, 
perhaps inadvertently, exited a script in the mid¬ 
dle of a Find sequence. If you enter a record full 
of data while in Find mode, you’ll 
have to enter it again after you 
have escaped back to Browse. But 
first you will need to be aware that 
the record you thought you en¬ 
tered is not really in the database. 

Check the tool bar on the left or 
the status indicator at the bottom 
of the window (both shown in 
Figure 1) to be sure you are in 
Browse and not Find. Sometimes 
having a New Record button that 
executes a script will prevent this 
difficulty. The script might first 
move to Browse and then create a 
new record ready for data entry. 


I®” Don't hurry through the print dialog box. 

It is easy to rush through the print dialog box, 
but you may have to restrain that fast finger move 
to the return or enter key. Some of the annoying 
mistakes available to you (not to mention the 
wasted trees and toner and time) are: 

• Print a nonsense report containing just one data 
line because you forgot to check Records Being 
Browsed instead of your normal Print Current 
Record. 

• Conversely, wanting to print only one record 
and getting dozens of pages. (Print Monitor is so 
fast that there is often no escape except to turn off 
the printer.) 

• Landscape mode came out when you wanted 
portrait (and vice versa), chopping off part of 
your layout. 

• Printing to the wrong printer and ending up 
with, say, some lovely reports on a couple of doz¬ 
en of your bank checks. 

• Printing a neat set of field definitions when the 
current record was desired. 

One way to avoid these types of problems is to 
define a group of navigation and printing scripts 
which include the appropriate page setup options. 
(Remember that in ScriptMaker the print dialog 
options are set under Restore Page 
Setup.) These scripts will save you 
a lot of grief. 


Remember that Preview 
shows all records in the found 
set, starting with record 1. 

A couple of versions ago, Claris 
added a Print Current Record 
option to the print dialog box. 
This is such a tremendously useful 
feature that it is easy to come to 
depend on it and to forget that 
there is no equivalent Preview 
Current Record feature. When 
working on a record in the middle 
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Figure 2 


of a large found set, it can seem like a move to 
Preview ought to show the record on which you 
are working. Actually, of course. Preview starts by 
showing you page 1 of all the records in the found 
set. To Preview the current record requires doing 
a Find for that one record before entering Pre¬ 
view, or knowing which record it is in the found 
set sequence and entering that number at the 
bottom of the FileMaker notebook after you enter 
Preview. 

Thanks to FileMaker Pro 2.0 scripting, you 
can also vnite a “Preview Current Record” script. 
The script can then be attached to a (non-print¬ 
ing) button which is readily available on those 
layouts where it might be needed. If you follow 
the suggestion above which says to always create a 
Record Number field in every file, then each of 
your records will have a unique record number 
and the script shown in Figure 2 will “Preview 
Current Record”. 

I'®’ Watch for field type(s) when writing 
calculation equations. 

The SFM that gets you here is forgetting to 
check and properly select the calculation result 
field type after finishing an equation. The default 


is a number result and it is particularly easy to 
forget to change the result type to text after writ¬ 
ing a text equation. If you have also been silly 
enough to violate the point above about experi¬ 
menting with equations in large files, then you’ll 
get the pleasure of watching a long calculation 
being run which you know is wrong. Of course, 
you get to wait through the same recalculation 
after correctly selecting the field type. 

Ever write a nice calculation that you knew 
was correct but that refused to provide the right 
answer? There is an excellent chance that one of 
the fields providing input to the calculation is of 
the wrong data type. Example: 

Filter = {text result} 

If (Type = "BHL" and Rev > 99, "Accept", "") 

If the Type field is defined as a numeric field, the 
Filter calculation will not work. FileMaker does 
not show the field types in the equation definition 
dialog, but you can print a list of field definitions 
to keep at your side. 

The most difficult field-type problems arise 
with time and date fields. FileMaker stores times 
and date internally as pure numbers and these 
numbers are used whenever you write an equa¬ 



tion that is less than 
exact about date and 
time formats. You’ll 
need to learn the nuanc¬ 
es of DateToText and 
similar functions to 
successfully write date 
and time equations. 

Watch out for 
invisible objects in 
layouts. 

When a Slide does 
not work properly or a 
Part cannot be moved 
where you want it, you 
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Figure 3 


maybe bumping against invisible layout objects. 
Some FileMaker tricks require invisible objects, as 
do some scripts, so it may be easy to have invisi¬ 
ble objects that you have forgotten about. To 
locate such objects simply Select All while in Lay¬ 
out to expose handles for all objects. 

Another way to lose text - layout text or field 
text - is to make it a color without a contrasting 
background color. The easy example is white text 
on a white background. See Figure 3. Select All 
works for this case too. 


Be aware of FileMaker's inclination to add 
newly-defined fields to the current layout. 

Until Pro 2.0, FileMaker always added a newly 
defined field to the bottom of the current layout, 
moving down the Body Part if necessary. This can 
mess up some finely crafted layouts. One way to 
avoid such disturbances is to have a working lay¬ 
out intended for use while defining fields. You 
might have a convenient button or script to take 
you to that layout when you want to define fields. 
(For some files it is nice anyway to have a layout 
that contains in a column all fields that have been 
defined - if such a layout is always current when 
defining fields, new ones can be added to the bot¬ 
tom.) Another way is to use the new Pro 2.0 Pref¬ 
erences to stop FileMaker from adding new fields 
to any layout. 

Use Extend on non-repeating fields that 
participate in repeating field calculations. 

This goof is really easy to make and hard to 
spot. Repeating field calculations assume that all 
elements in the equation come from repeating 
fields. There are often situations, however, where 


it is desirable to use a non-repeating value in an 
equation with a repeating result. Example: in an 
invoice file a series of repeating fields are usually 
used to hold the list of items sold. The rub comes 
if you want to include a customer discount when 
computing the price of each line item. The cus¬ 
tomer discount will usually be in a nonrepeating 
field, yet is meant to apply to all line items. This 
equation works for only the first line: 

LineTotal = {numeric result} 

UnitPrice * Quantity * Discount 

To be useful for all lines, the equation should 
look like: 

LineTotal = (numeric result} 

UnitPrice * Quantity * Extend (Discount) 

As files become more sophisticated this prob¬ 
lem appears in many subtle and hard-to-detect 
forms. Be watchful. 

Similarly, always design repeating fields used 
as input to a calculation to have the same number 
of repeats - part of our job, after all, is to help 
keep FileMaker from becoming confused. 

And remember it is also easy to forget to indi¬ 
cate the number of repeats required for the result, 
which has to be done (for equations) in the equa¬ 
tion definition dialog. Naturally, you often realize 
you forgot to enter the proper number of repeats 
just after you've closed the calculation window. 

■S" Don't confuse and "and" in equations. 

FileMaker makes creating equations incredi¬ 
bly easy: every field, function, and operator is 
available to be inserted into an equation with a 
simple mouse click. It is easy to build a complex 
calculation without ever touching the keyboard. 
But we still need to click the right item. One area 
of confusion is and “and”. The ampersand 
(&) is a text operator used to concatenate two text 
strings. The word “and” is a logical operator used 
when building compound conditions into a for- 
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mula. When lost in thought during a creative 
frenzy it is easy to use the wrong one. Often the 
calculation will be accepted but will provide in¬ 
correct results. This SFM recently consumed an 
extra frustrating hour of debugging time before 
the simple mistake was discovered. 
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Q & Si: Calculating the Latest of Three Dates 


By Joe Kroeger 


LatestDate = Max (DateList) {date result} 


“In one of my FileMaker address files, I have three 
date fields in each record. One is for the date the 
record was entered, one is for the last time the 
addressee placed an order, and one is for the last 
time the address was updated. Once in a while I 
need to know the latest date that the address was 
known to be valid and I want to create a calcula¬ 
tion that presents the latest of the three date fields. 
I’ve tried a few combinations of If functions, but 
so far it works only partially. Help!” 

- R. A., Phoenix. 

M 

Sometimes just reorganizing information can 
simplify a calculation problem. I suggest that you 
arrange, if you can, to have the three dates appear 
in a three-deep repeating field. Then the Maxi¬ 
mum function can be used to calculate the most- 
recent date. Like this: 


DateList is a repeating field with three repeats. 
Figure 1 shows an example. 


DateA 

DateB 

DateC 


7 / 7/88 

8 / 8/88 

6 / 6/88 


LatestDate 


08 / 08/88 


If it is awkward or impossible for you to enter 
the appropriate dates into DateList - perhaps one 
date is calculated or another is auto-entered - 
then you can try Answer 2. 

This approach is fun - complex enough to be 
interesting, yet amenable to careful analysis. And 
the resulting calculations show how nested If 
statements can be a powerful technique for solv¬ 
ing many types of FileMaker problems. 
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Let’s define three independent date fields and 
call them DateA, DateB and DateC. (For a real 
database you would likely use more descriptive 
field names, but for this article the simple names 
make the calculations easier to follow.) We’ll cre¬ 
ate a calculation called LatestDate to figure out 
which of the three dates is the most recent. Each 
equation is named in sequence within the field- 
type curly brackets. 

First of all, we know how to compare just two 
dates: 

LatestDate = {date result, EQ1} 

If (DateA > DateB, DateA, DateB) 

In words, this calculation says “If DateA is 
greater than DateB, put DateA in the LatestDate 
field, otherwise put DateB in the LatestDate field.” 
(If LatestDate is defined as a date-type field, and 
if DateA and DateB are date-type fields, we don’t 
need to worry about conversions to-and-ffom date 
data.) 

Note that if both input dates are the same it 
does not matter which is put into LatestDate, but 
in fact it wiU be DateB when EQl is used. A varia¬ 
tion of the equation allows DateA to get used 
when the two are the same: 

LatestDate = If (DateA > DateB, DateA, DateB) 


The generic If function looks like: 

FieldA = If (Test, True Result, False Result) 

A logical test is performed that has a binary out¬ 
come: true or false. The test can examine the con¬ 
tents of another field or fields, perhaps in con¬ 
junction with a constant or another calculation. 
Indeed the test can even be another If statement. 
Depending on the outcome of the test, one of the 
two available results is placed into FieldA. The 
results can be constants, other fields, other calc¬ 
ulations or even other If statements. 


So far, so good. When we go beyond the com¬ 
parison of two dates we can make use of this same 
basic relationship, but the calculation does get 
busier. The key to accumulating an equation that 
works is to be systematic about tracing the effect 
of each subset of results. And remember that in If 
functions, FileMaker ignores decision branches 
not taken. 

Let’s expand the EQl calculation by nesting 
another If to insert consideration of the DateC 
field as well: 

LatestDate = {date result, EQ2} 

If (DateA > DateB, If (DateA > DateC, DateA, 
DateC), ... 

Note that in place of the True Result portion 
of the generic If, we have entered an additional If 
function (often called a nested If). The compari¬ 
son “DateA > DateC” does not stand alone but is 
located on one branch of the earlier “DateA > 
DateB” comparison. Thus we have made a two- 
step condition and the results of the second If are 
applied in tandem to the results of the first. 

We have accomplished two tests of the DateA 
field. Once we know that DateA is later than both 
DateB and DateC, then the result in LatestDate 
should be DateA - under these conditions we will 
have traced our way to pointer 1 in Figure 2. Log¬ 
ically, we don’t need to know anything else or 
make any other tests to declare with certainty that 
DateA is the latest date of the three if the condi¬ 
tions are such that we arrive at the pointer 1 loca¬ 
tion; our quest is done. If either DateB or DateC 
is later than DateA, on the other hand, we will 
not arrive at arrow 1. 

Without going further we’ve also accom¬ 
plished something more: when DateA is later 
than DateB but is not later than DateC, we know 
that DateC must logically be the latest date - no 
other conclusion is possible - and DateC should 
therefore be the result (pointer 2 in Figure 2). 

There remains a branch of the first test that 
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we have not yet examined. At the first If function, 
what if DateA is «ot greater than DateB? Then the 
balance of EQ2 is bypassed and we must extend 
the equation to take the alternative possibility 
into consideration. EQ3 completes the tests: 

LatestDate = {date result, EQ3} 

If (DateA > DateB, If (DateA > DateC, DateA, 
DateC), If (DateB > DateC, DateB, DateC)) 


than DateC, we arrive at point 5 in Figure 3. For 
the task of locating the latest of three dates our 
work is done - we have covered aU the possible 
combinations. 

Naturally, this approach can be extended into 
more than three date comparisons, but it gets 
complex quickly as the number of dates to be 
examined grows past three. 

It appears that EQ3 works properly in either 


3 4 5 ^ 

LatestDate = Y V V = 

If (DateR > DateB, If (DateR > DateC, DateR, DateC), If (DateB > DateC, DateB, DateC)) ~ 


In EQ3 we arrive at point 3 (see Figure 3) 
when DateA is not later than DateB in the first 
test. Another If function is introduced at point 3 
to make another comparison decision. 

What do we need the If to decide? We already 
know that DateA is not the latest date - we would 
otherwise not have arrived at point 3 - and we 
have thus eliminated further consideration of 
DateA. Now we need to figure out if DateB or 
DateC is the latest. We are really just building a 
simple two-date comparison like that in EQl. 
When DateB is later than DateC, we arrive at 
point 4 in Figure, 3 and when DateB is not later 


Pro 1.0 or Pro 2.0 when any of the date fields is 
empty or even when any two of the date fields are 
empty. Nonetheless, as a learning exercise, we can 
consider changes that would be necessary if we 
wanted to take explicit account of empty fields. 
We may learn something about additional nesting 
of If functions even though EQ3 already works. 

Let us assume that DateA or DateB or both might 
be empty, but that DateC always contains a date. 
We can add additional tests to see if a date exists 
in a field. Appending additional tests to the exist- 


LatestDate = 

If (DateR >TeKtToDate (1/1/11) and DateB >TeKtToDate (1/1/11), 3 

If (DateR > DateB, If (DateR > DateC, DateR, DateC), ll 

If (DateB > DateC, DateB, DateC)), 

If (DateR >TeKtToDate (1/1/11), 

If (DateR > DateC, DateR, DateC), 

If (DateB > DateC, DateB, DateC))) 
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ing EQ3 makes it a little easier to follow as an 
extension to the work we’ve already done. In EQ4 
the conditional test in the first If statement checks 
for the presence of dates later than January 1, 

1911, in both DateA and DateB. When the an¬ 
swer is yes, our old EQ3 equation comes into 
effect starting at the second If. (Figure 4 shows 
each If on a separate line.) Note that 1/1/11 by 
itself looks to FileMaker like some kind of strange 
division operation if the TextToDate function is 
not included, even if you put quote marks around 
it. By the way, 1/1/11 is arbitrary but is selected 
because it is easy to type. 

If either DateA or DateB is empty, EQ4 skips 
over the branch where the old EQ3 calculation 
lives and moves to the fourth If. What remains to 
be tested? We know that either DateA or DateB is 
empty and we want to test the one that is not 
empty against DateC - thus we are back to our 
simple EQl two-date test. We just have to test the 


right fields. The fourth If in Figure 4 checks the 
emptyness of DateA. If it contains a date we know 
that DateB is empty and DateA is then tested 
against DateC in the fifth If. Otherwise we know 
that DateA is empty so the sixth If comes into 
play to test DateB against DateC. 

There is one other possible condition: what if 
both DateA and DateB are empty? In such a case 
the latest date musthe DateC - the other two are, 
after all, empty. This case falls out of the last two 
If statements. 

LatestDate = {date result, EQ4} 

If (DateA > TextToDate (1/1/11) and DateB > 
TextToDate (1/1/11), If (DateA > DateB, If 
(DateA > DateC, DateA, DateC), If (DateB > 
DateC, DateB, DateC)), If (DateA > TextToDate 
(1/1/11), If (DateA > DateC, DateA, DateC), If 
(DateB > DateC, DateB, DateC))) 


New Numbers 

Elk Horn Publishing has moved. In issue #48 we published a new phone number. Unfortunately it 
turned out to be a wrong number (unless, that is, you wanted a way to not get hold of us). Please ignore 
past references to a ‘700’ number and delete it from your records and your mind. 

Here is the proper new telephone number: 

408 - 726-1232 

Our new fax number is: 

408 - 726-1233 

Please add these numbers to your records and pass them along to others who should know - your pur¬ 
chasing department, for example. 

Our mail address remains: 

Elk Horn Publishing 
PO Box 1300 
Freedom, CA 95019 USA 
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A Birthday and Anniversary Reminder System 


By Dan Gesmer 

I DEVELOPED A Straightforward system to 
keep track of birthdays and anniversaries in my 
FileMaker name and address file. Once an indi¬ 
vidual’s birth date or wedding date is entered, 
that person’s age, or the years he or she has been 
married, is automatically calculated. Other fields 
calculate the number of days until the next birth¬ 
day or anniversary. A simple script can then in¬ 
form you of every birthday or anniversary coming 
up within, say, the next two weeks or so. 

Some of the name fields in your present data¬ 
base (First Name, Middle Initial, Last Name, 
etc.) maybe repeating. This makes it possible to 
record the names of multiple individuals (family 
members or business employees) within a single 
record. In that case, simply make the following 
fields repeating, with the same number of repeti¬ 
tions as in your name fields. 

For the sake of simplicity, though, let’s just 
assume that your name fields are all non-repeat¬ 
ing, and that one record is assigned to every 
name. 

The first fields you’ll need to create are Birth 
Date and Anniversary Date fields. Be sure to 
specify them as Date-Type fields. Working with 
these fields is very straightforward - just enter the 
dates on which any given individual was born 
and/or married. 

With the data fields in place we need next to 
design calculation fields to derive for us the de¬ 
sired information. Create Age and Years Married 
calculation fields, as follows: 

Age = {numeric result} 

Year (Today) - Year (Birth Date) - (If (DayOfYear 
(Today) < DayOfYear (Birth Date), 1, 0)) 


Years Married = (numeric result} 

Year (Today) - Year (Anniversary) - (If (DayOfYear 
(Today) < DayOfYear (Anniversary), 1, 0)) 

These fields will calculate the exact age or 
years-married of your friends, relatives, and/or 
acquaintances. This method simply gets the raw 
difference in years and then adjusts for Today 
being earlier or later than the target day. 

Next, create Birthday Countdown and Anni¬ 
versary Countdown fields, like this: 

Birthday Countdown = (numeric result} 

If (DayOfYear (Birth Date) > DayOfYear (Today), 
DayOfYear (Birth Date) - DayOfYear (Today), 365 
- (DayOfYear (Today) - DayOfYear (Birth Date))) 

Anniversary Countdown = (numeric result} 

If (DayOfYear (Anniversary) > DayOfYear (Today), 
DayOfYear (Anniversary) - DayOfYear (Today), 
365 - (DayOfYear (Today) - DayOfYear 
(Anniversary))) 

These calculations provide the number of 
days remaining until the individual’s next birth¬ 
day or anniversary. 

By setting up a script to search for all records 
in which the value for Birthday Countdown or 
Anniversary Countdown is less than a given 
number of days (I use 14 days), you can alert your¬ 
self to send greeting cards and gifts. 

If you have trouble remembering birthdays 
and anniversaries like I do, this set-up may be just 
the thing. The basic techniques are handy for 
other date applications as well. 

Dan Gesmer is at Seismic Skate Systems Inc. and 
develops custom FileMaker databases. Write or call: 

2504 Cerro Vista Drive 
Rockford, IL 61107 
phone 815-637-4017 
fax 815-637-4018 
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FileMaker Quick Tips & Techniques 


By Joe Kroeger 


Repeating Field Sequence Numbers 

If you use some of the famous Mike Harris 
repeating field tricks, you have assigned a sub- 
serial number to each line of your repeating field 
set. The sub-serial is often derived from the 
RecordSerial. It might look like Figure 1. The 
RecordSerial in this example is multiplied by 10 


RecordSerial 

107966 


RptSerial Seq* 


1079660 


0 

1079661 


1 

1079662 


2 

1079663 


3 

1079664 


4 

1079665 


5 

1079666 


6 

1079667 


7 

1079668 


8 

1079669 


9 


45 


and the Seq# is then add¬ 
ed to it to produce the 
repeating RptSerial num¬ 
bers. The Seq# data is the 
same in all records. File¬ 
Maker can’t auto-enter 
repeating field data when 
a new record is created so 
I use a small, one-record 
lookup file (Figure 2) to 
fill Seq# for each new 
record. (The lookup uses 
RecordSerial or the next 
smaller value as the look¬ 
up key so it always finds 



the single record in the lookup file.) So far so 
good. 

When records are imported, however, things 
can be a little trickier. Lookups don’t happen 
during an import. A Relookup won’t work with¬ 
out RecordSerial numbers. RecordSerial num¬ 
bers need to be unique. And a Relookup takes a 
very long time for a complex file. In addition, my 
file design had evolved from an earlier version 
with fewer repeating field lines. Thus, after a cou¬ 
ple of imports, I had some records with full Seq#, 
some with partially full, and some with none at 
all. Any empty Seq# slot, of course, causes the 
RptSerial to be wrong and operations that de¬ 
pend on it cannot be executed. 

I tried simply doing a Replace for each Seq# 
slot. But with several calculations dependent on 
Seq# and in a large file, it took a very long time to 
do each one. So I gave up after the first attempt. 
Then I tried finding records that had an empty 
slot (Omit records with an “8” in Seq#, for exam¬ 
ple.) and doing a Replace on just those. This was 
better but it took a long time to do the Find, the 
Replace was not much quicker, both needed to be 
repeated for each slot, and the whole process 
needed to be repeated for 
each batch of imported 
records. 

But the biggest prob¬ 
lem was that I made an 
error and created a bunch 
of records with duplicate 
Seq# entries (see Figure 3). 

Had I not caught them it 
would have been a disaster 
to have attempted an oper¬ 
ation that relied on the 
RptSerial numbers being 
unique. I decided that I 


RecordSeria l 

107966 


RptSerial Seq* 


1079660 


0 

1079661 


1 

1079662 


2 

1079663 


3 

1079664 


4 

1079665 


5 

1079667 


7 

1079667 


7 

1079668 


8 

1079669 


9 
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Figure 3 









needed some kind of parity value to help assure 
the integrity of Seq#. I created a SeqSum calcula¬ 
tion which is the Sum (a repeating field function) 
in each record of the contents of Seq#. You can 
see this field at the bottom of Figures 1 and 3.1 
know that something is wrong with any record 
that does not have 45 in the SeqSum field - that 
is, 45 = 0+l-l-2-l-3-l-4-l-5-l-6-l-7-t8-l-9. It catches par¬ 
tially-filled Seq# fields and incorrect entries. It 
does not detect reversed values (e.g., a 7 in the 6 
slot and a 6 in the 7 slot), but reversed values 
don’t often cause problems. 

Replace still took a long time, but the records 
that need Seq# work are easier and faster to lo¬ 
cate. And long Replace times gave me a good 
excuse to buy a faster computer. 

Clearing a Field 

Subscriber Klaus Lotz points out that if you 
have an extended keyboard the contents of a field 
can be erased completely by clicking or tabbing 
into the field and then hitting the c/enr button on 
the numeric keypad. This saves a step by not re¬ 
quiring Select All before hitting delete. 

Auto-Format New Layout Fields 

Klaus also points out that you can copy the 
style and formats from an existing field when 
adding new fields to a layout. Just hold down the 
command key, click on a field that already has the 
desired format, let go of the command key and 
then drag the new field out of the field well. Saves 
a lot of time. 

Repeating Functions Sum and Count 

Several of the FileMaker functions available 
for building calculations are designed for use only 
with repeating fields. The Sum function is an 
example; Sum computes the total of the values of 
the entries in a numeric repeating field. It is used 
for adding up things like line item dollar amounts 
to get a total amount. Count is another function 


that applies only to repeating fields. It does not 
add up the values of entries in the repeating field 
- instead, it adds up the number of entries. 

Please note that neither function provides a 
zero result. That is, if there are no entries at all in 
the repeating field, both the Sum and Count 
functions return nothing at all rather than the 
zero that we would expect. Don’t use these func¬ 
tions to detect empty repeating 
fields. 

Both Sum and Count func¬ 
tions should be specified as 
having numeric results. Sum 
only makes sense 


CountList 

SumList 


CountList 

SumList 


List 


1 


List 


10 


when adding up 
numeric values 
from a numeric 
repeating field. 

Count can count entries in any 
type of repeating field if the 
type of entries match the field 
type. Entries that do not match 
cause strange results. Figure 4 
shows proper op¬ 
eration. List is a 
numeric repeating 
field. CountList is 
a Count of List 
and SumList is a Sum of List. 

Figure 5 is exactly the same 
setup except that one of the 
repeating lines contains a text 
value that produces the wrong 
results shown. Other text values 
do not produce 

wrong results - see CountLIst 

Figure 6. The les- SumLIst 
son is clear: be very 
careful to make sure that repeating fields that are 
to be summed or counted contain only values 
that match their field type. 


List 
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Figure 8 Figure 7 


Locking Lookup Files 

It will often be an advantage to lock lookup 
files that don’t get modified as part of their nor¬ 
mal operation. Files are locked in the Get-Info 
box (Figure 7) by clicking to put an “x” in the 


ioi 


Zip Table Info 




Zip Table 


Kind: FileMaker Pro 2.0v3 document 
Size: 2.2 MB on disk (2,383,872 bytes 
used) 

Vhere: JK 500: Gaz Items: 


Created: Mon, Nov 9, 1992, 9:10 PM 
Modified: Tue, Apr 13, 1993, 8:01 AM 

Version: n/a 

Comments: 


Locked 


□ 


Locked box in the lower left-hand corner. (To 
make a change, simply unlock it.) 

There are two advantages to lock¬ 
ing lookups. One is that since the file 
can’t be modified, backup programs 
do not know that it has been used. 

This is true at least for DiskFit. (An 
unlocked FileMaker file has only to 
be opened to then register with back¬ 
up programs as having been modi¬ 
fied.) The second advantage is that in 
the event of an ungraceful shut¬ 
down, Claris tells us that the locked 
file will not need to be repaired. 

The only disadvantage of locked 
lookups that I have found so far is that the first 


o 


o 


time a lookup is attempted, a dialog box appears 
(see Figure 8) to report the locked status. This 
adds one more step - dismissing the dialog - for 
the first lookup. Take care to always click OK 
rather than Cancel. The Cancel button cancels 
the whole lookup and you’ll need to close the 
target file and start over. Clicking OK opens the 
lookup and the dialog will not appear again (for 
this file) until it has been closed and needs to be 
opened again. 

Invalid Dates 

The dialog box shown in Figure 9 occurs 
when FileMaker Pro 1.0 detects a difficulty with 
an entry in a date field. It could be a format prob¬ 
lem, as indicated, or a range problem. But anoth¬ 
er error is not specified in the dialog and may not 
be obvious when you are examining your entry 
and trying to debug it. A date like 2/30/93 looks 
harmless enough but causes the error box. It took 
me a while to figure out that there is no date of 
February 30! So Figure 9 indicates not only wrong 


The date In this field should look like 7/22/88 or 
7-22-1988, and must be between 1/1/0001 and 
12/31/3000. 


» H 


The date In this field must be a ualld date In the 
range of years 1 to 3000 and should look like 
“10/31/91”. 


11 i 


“ZIP Table” Is locked or In use. Vou will not be 
able to make changes. 


[ Cancel H 


formats but invalid dates as well. I tried 3/33/93, a 
more obviously bad date, and sure 
enough it fails as well. FileMaker Pro 
2.0 has an improved error dialog 
(Figure 10) that includes “valid 
date” injunction to cover instances 
like 2/30/93. ^ 
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